Subject: RSRR interface proposal, Flow IDs, and other comments

From: Daniel Zappala <[email-masked]>
Date: Tue, 05 Aug 97 20:38:35 PST

It is important to note that while RSVP operates independently of
routing protocols, it is in fact dependent on the IP protocol and its
forwarding mechanism.  This dependence currently manifests itself in two
ways:

1) RSVP is designed to put reservations in place for an application
along the same route that the application's data will use.  
The way RSVP does this is by knowing which fields of a packet IP uses to
lookup its forwarding entry.  RSVP takes those fields, sends them to
routing, and asks for the appropriate forwarding entry associated with
the fields.  RSVP then caches this forwarding entry and uses it to
forward PATH messages.  RESV messages then follow the cached forwarding
entries upstream to reach the sender.

2) RSVP must also distinguish different sessions.  RSVP again does
this by using the same identifiers that applications use to distinguish
different flows: the source and destination ports and addresses.  When
several RESV messages arrive at a node, the way RSVP knows whether they
belong to the same session (and should be merged) or different sessions
(and are distinct) is by looking at these identifying fields.

What this means is that if the IP forwarding mechanism is changed to
use some label in the packet, then RSVP needs to be aware of the
label's existence and use it for (1) forwarding and (2) identification
of sessions.  Likewise, if data is going to use a source route, then
RSVP needs to use the source route for forwarding and use some
source route identifier as part of the session identification.

In the Guerin et al. proposal (draft-guerin-ext-rsvp-routing-intf-00),
the authors suggest that extra forwarding information (source routes,
labels) be carried in opaque objects.  RSVP hands all the opaque routing
objects to the routing protocol for interpretation.  This will work for
(1) but breaks (2).  If a sender is transmitting different data for the
same destination, but some with a label and some without (i.e. for some
policy or QoS routing reason), then RSVP won't be able to treat the data
as coming from two different sessions.  It will merge the reservations
where the paths overlap instead of keeping them distinct.

In sum, the draft needs to include a routing object that carries a
unique flow id that is visible to RSVP.  If this object is absent, RSVP
assumes the usual session identifiers.  The semantics of this object
should be defined, i.e. is it in addition to address and port
identifiers or does the identifier include all that is needed to
be globally unique (i.e. it includes the relevant addresses/ports
inside of it).

The RSRR interface has, to this point, carried a QUERY id, not a flow
ID.  The query id is purely local to a router and references the query,
not the flow, so that RSVP can match a response to the query using a
fast lookup.

The Guerin et al. draft (draft-guerin-ext-rsvp-routing-intf-00)
references a flow id in the interface, but doesn't explain what it is.
If this indeed the type of flow id I'm talking about, then it needs to
be talked about more explicitly as such and I think it needs to be
carried in a special transparent object with the Path message.

Depending on how the flow id is interpreted, this could mean
some changes to the interface.  (I.e. does it pass the network
and transport headers and the flow id separately, or is there
just one object used to identify the flow, part of it including
a visible flow id, part of it the opaque network and transport headers?)

I am very much against passing the sender tspec and adspec across the
interface until it can be shown that someone is really going to do
hop-by-hop QoS routing and make it stable.  QoS routes are going to be
computed at the sender or the receivers, then the tspec and adspec don't
need to be included in RSRR, which is a hop-by-hop interface.  Instead,
they can be passed to the QoS route computation entity at the sender or
receiver using some other interface.

I think putting source routes in the Path message is an OK thing to
do but only if that is what the data will be doing too.  If the data
is using a label, then Path messages should only carry a label.  I
think it is much easier to prevent strange things from happening if
Path messages and data are forwarded the same.

I also think it is a bad idea to try to push MPLS path setup into
the Path message.  It's a nice idea to try to reduce the setup time,
but is it really important for the type of long-term flow that MPLS
and RSVP will be serving?  This need may be outweighed by the advantages
of keeping the MPLS setup mechanism separate from RSVP, so that
the two can be developed separately as needed.  Off the top of my
head I can already think of complexities arising when only part
of the path uses MPLS and the rest does not.

Which reminds me, it's also not a good idea to use partial source routes
in the PATH message.  Otherwise you get common looping problems where
normal IP forwarding after the end of the route loops the PATH message
back to the router that adds the source route.  I'm forgetting the
problems with loose source routes, but they seemed to cause headaches
for us in the past too.  It has always been a safer design to mandate
complete strict routes and prevent any problems.

Daniel Zappala
[email-masked]
http://netweb.usc.edu/daniel

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 6 Aug 97 15:07:22 JST

Daniel;

> Likewise, if data is going to use a source route, then

As the use of the source route destroys the fundamental properties
of RSVP such as scalability for large multicast groups and the
capability of dynamic routing, there is no point for RSVP
carry the source route information.

							Masataka Ohta

---

From: Tony Li <[email-masked]>
Date: 05 Aug 1997 23:50:35 -0700

Danny,

> unique flow id that is visible to RSVP.  

Agreed.

> If this object is absent, RSVP

In fact, since it may represent an aggregated flow, it may be sufficient to
make it globally unique.

> carried in a special transparent object with the Path message.

Again agreed.

> and RSVP will be serving?  

Consider the situation where you want to set up an MPLS path which also
requires QoS.  The point of carrying MPLS path setup in RSVP is _not_ to
cut down the setup time (tho that's nice ;-) but the fact that we need the
cross product of both functionalities simultaneously.  

As a result, the alternative to putting MPLS path setup into RSVP is to
basically recreate all of RSVP in the MPLS path setup protocol.

> complete strict routes and prevent any problems.

In fact, you should note that the difficulties with any type of partial
source route are completely orthogonal to MPLS or RSVP.  They're quite
apparent with IPv4 source routing and any node which can create an explicit
source route other than the source.  You might also note that this is a
problem for routing to solve, but one which we need to be very concious of
when computing explicit routes.

Tony

---

From: Roch Guerin <[email-masked]>
Date: Wed, 06 Aug 97 08:41:52 -0400

Daniel,

Overall, I agree with your comments regarding the need to increase
RSVP awareness to ensure proper coordination between forwarding and
resource reservation.  However, I think that the label based
forwarding and the explicit route cases are somewhat different,
although they certainly can be used jointly, i.e., label based
forwarding on an explicit route.  Specifically, you say:

>of sessions.  

There, I totally agree.  Actually, in the earlier prototype
implementation we had, RSVP's awareness of the label to be used was
ensured by having the label carried in the LIH field (that was
described in draft-williams-issll-vcuse-00.txt).  Clearly, there are
other (better) ways of doing it, and including a label object as you
mention may indeed be desirable.  Now, if RSVP is aware of that object
and its use in forwarding data packets, then it is not clear whether
it needs to pass it to the path selection/management component
(routing), so that the flow_id currently in the interface need not be
extended. 

>source route identifier as part of the session identification.

Here, I'm not sure I agree.  If the forwarding is based on a
classifier that operates on the same information as today (src/dest
address +ports), then I don't see any need for RSVP to be aware of the
explicit route.  Note that I'm assuming here some grouping of the
classification and forwarding functions.  In such a case, the next hop
information returned by routing (in addition to the modified route
object), is sufficient to ensure consistent forwarding and resource
reservation as it is the case today.  So, I think we need to decouple
the two things, label based forwarding and use of an explicit route,
in terms of what RSVP needs to be aware of.

Coming now to some of the other aspects you raise, I have a couple of
other comments.

>receiver using some other interface.

I'd rather not have multiple interfaces and also it is likely that you
would need that interface at other nodes than the sender or receiver.
For example, the initial explicit route may only be specified at the
AS level and needs to be "expanded" at each boundary.  

>Path messages and data are forwarded the same.

Not sure I completely follow you here.  If you mean that PATH and data
packets should follow the same "path", then I agree.  If you mean that
they should both use the same *forwarding* information (label), then I
don't agree (even today that's not the case).

Roch